CLAIMS 



What is claimed is: 

5 1 . A system for implementing personal area networking on a local machine having 
one or more local Bluetooth devices, the system comprising: 

a list of device control blocks (DCBs), wherein a DCB is associated with a local 
Bluetooth device; and 

a list of connection control blocks (CCBs) associated with a DCB, wherein a CCB 
10 is associated with a remote Bluetooth device having a connection to a local Bluetooth 
device. 

2. The system of claim 1 , further comprising: 

a transmit packet queue associated with each CCB; and 
15 a receive packet queue associated with each CCB. 

3. The system of claim 2, further comprising: 
an additional transmit packet queue. 

20 4. The system of claim 3 wherein the additional transmit packet queue supports a 
priority scheme. 

5. The system of claim 3 wherein the additional transmit packet queue supports a 
quality-of-service scheme. 
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6. The system of claim 1 wherein the local machine has at least two local Bluetooth 
devices, wherein selection of a local device for establishing a connection to a remote 
device is performed randomly. 

5 

7. The system of claim 1 wherein the local machine has at least two local Bluetooth 
devices, wherein selection of a local device for establishing a connection to a remote 
device is based on a balancing scheme. 

10 8. A method for enabling personal area networking on a Bluetooth device, the 
method comprising: 

controlling state of a device control block (DCB). 

9. The method of claim 8 wherein controlling the state of the DCB comprises: 
when the Bluetooth device is added, causing the DCB to enter an idle state; 
from the idle state, in response to a halt request event, entering a halt wait state; 
from the idle state, in response to a connection control block (CCB) established 
event, causing the DCB to enter a busy state; 

from the busy state, in response to a CCB teardown event reducing to zero a count 
of CCBs associated with the DCB, causing the DCB to return to the idle state; 

from the busy state, in response to a CCB established event, causing the DCB to 
remain in the busy state; 

from the busy state, in response to a halt request event, causing the DCB to enter 
the halt wait state; 
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from the halt wait state, in response to a CCB teardown event reducing to zero a 
count of CCBs associated with the DCB, causing the DCB to enter a halting state; 

from the halt wait state, in response to a CCB teardown failed event, causing the 
DCB to enter a zombie state; 
5 from the halting state, in response to a halt complete event, causing the DCB to 

enter a halted state; and 

from the halted state, in response to a device remove event, causing the DCB to 
enter a terminal state. 



10 10. A method for controlling a connection on a Bluetooth PAN device, the method 
comprising: 

controlling state of an L2CAP connection control block (CCB); and 
controlling state of a BNEP CCB. 

15 11. The method of claim 1 0 wherein controlling the state of the L2CAP CCB 
comprises: 

initially causing the L2CAP CCB to enter a closed state; 

from the closed state, in response to an open initialize event, causing the L2CAP 
CCB to enter an opening state; 
20 from the opening state, in response to an open fail event, causing the L2CAP CCB 

to enter a closing state; 

from the opening state, in response to a close initialize event, causing the L2CAP 
CCB to enter a close wait state; 

from the opening state, in response to an open success state, causing the L2CAP 
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CCB to enter an open state; 

from the closing state, in response to a close success event, having the L2CAP 
CCB enter a terminal state; 

from the closing state, in response to a close fail event, having the L2CAP CCB 
5 enter a zombie state; 

from the close wait state, in response to a close issue event, having the L2CAP 
CCB enter the closing state; 

from the open state, in response to the close initialize event, having the L2CAP 
CCB enter the close wait state; 
10 from the open state, in response to the open fail event, having the L2CAP CCB 

enter the close wait state; and 

from the open state, in response to an open finalize event, having the L2CAP CCB 
remain in the open state. 



15 12. The method of claim 10 wherein controlling the state of the BNEP CCB 
comprises: 

initially causing the BNEP CCB to enter a closed state; 

from the closed state, in response to a connect request passive event, causing the 
BNEP CCB to enter an opening passive state; 
20 from the closed state, in response to a connect request active event, causing the 

BNEP CCB to enter an opening active state; 

from the opening passive state, in response to a successful connect complete 
event, causing the BNEP CCB to enter an open state; 

from the opening passive state, in response to a disconnect request event, causing 
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the BNEP CCB to enter the closed state; 

from the opening active state, in response to a successful connect complete event, 
causing the BNEP CCB to enter an open state; 

from the opening active state, in response to a disconnect request event, causing 
5 the BNEP CCB to enter the closed state; and 

from the open state, in response to a disconnect request event, causing the BNEP 
CCB to enter the closed state. 

13. A system for enabling personal area networking on a Bluetooth device, the system 
10 comprising: 

a finite state machine associated with a device control block (DCB). 



14. The system of claim 13 wherein the finite state machine associated with the DCB 
comprises: 

1 5 a plurality of states, further comprising an idle state, a busy state, a halt wait state, 

a zombie state, a halting state, and a halted state ; 

a plurality of transition events, further comprising a device add event, a 
connection control block (CCB) teardown event, a CCB established event, a halt request 
event, a CCB teardown failed event, a halt complete event, and a device remove event; 

20 and 

a plurality of transitions, further comprising: 

an initial transition to the idle state, associated with the device add event; 
a transition from the idle state to the halt wait state, associated with the 
halt request event; 
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a transition from the idle state to the busy state, associated with the CCB 
established event; 

a transition from the busy state to the idle state, associated with the 
CCB teardown event and a zero CCB count; 

a transition from the busy state to the busy state, associated with the CCB 
established event; 

a transition from the busy state to the halt wait state, associated with the 
halt request event; 

a transition from the halt wait state to the zombie state, associated with the 
CCB teardown failed event; 

a transition from the halt wait state to the halting state, associated with the 
CCB teardown event and a zero CCB count; 

a transition from the halting state to the halted state, associated with the 
halt complete event; and 

a transition from the halted state to a terminal state, associated with the 
device remove event. 

15. A system for controlling a connection on a Bluetooth PAN device, the system 
comprising: 

a finite state machine associated with an L2CAP connection control block (CCB); 

and 

a finite state machine associated with a BNEP CCB. 

16. The system of claim 15 wherein the finite state machine associated with the 
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L2CAP CCB comprises: 

a plurality of states, further comprising a closed state, an opening state, a closing 
state, a close wait state, an open state, and a zombie state; 

a plurality of transition events, further comprising a connect request event, an 
open initialize event, a close success event, a close issue event, a close initialize event, an 
open fail event, an open success event, a close fail event, and an open finalize event; and 
a plurality of transitions, further comprising: 

a transition from an initial state to the closed state, associated with the 
connect request event and a connection count not exceeding a maximum; 

a transition from the closed state to the opening state, associated with the 
open initialize event; 

a transition from the opening state to the closing state, associated with the 
open fail event; 

a transition from the opening state to the close wait state, associated with 
the close initialize event; 

a transition from the opening state to the open state, associated with the 
open success event; 

a transition from the closing state to a terminal state, associated with the 
close success event; 

a transition from the closing state to the zombie state, associated with the 
close fail event; 

a transition from the close wait state to the closing state, associated with 
the close issue event; 

a transition from the open state to the close wait state, associated with the 
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close initialize event; 

a transition from the open state to the close wait state, associated with the 
open fail event; and 

a transition from the open state to the open state, associated with the open 

finalize event. 

17. The system of claim 15 wherein the finite state machine associated with the BNEP 
CCB comprises: 

a plurality of states, further comprising a closed state, an opening passive state, an 
opening active state, and an open state; 

a plurality of transition events, further comprising a connect request passive event, 
a connect request active event, a disconnect request event, and a connect complete event; 
and 

a plurality of transitions, further comprising: 

a transition from an initial state to the closed state; 

a transition from the closed state to the opening passive state, associated 
with the connect request passive event; 

a transition from the closed state to the opening active state, associated 
with the connect request active event; 

a transition from the opening passive state to the open state, associated 
with the connect complete event; 

a transition from the opening passive state to the closed state, associated 
with the disconnect request event; 

a transition from the opening active state to the open state, associated with 
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the connect complete event; 

a transition from the opening active state to the closed state, associated 
with the disconnect request event; and 

a transition from the open state to the closed state, associated with the 
5 disconnect request event. 

1 8. The system of claim 1 7 wherein the disconnect request event is due to one of (a) a 
peer, (b) a local user, and (c) a connection failure. 

10 19. A method for setting and advertising multiple PAN profile roles in a Bluetooth 
device, the method comprising: 

operating as a PANU while advertising a PANU role and a GN service; 
if a remote device attempts to connect to the GN service, switching to providing 
the GN service, and removing a PANU SDP service record; 
15 if no remote user of the GN service remains connected, switching back to 

providing the PANU role, readvertising the PANU role, and retaining a GN SDP service 
record; 

if a local user manually creates a bridge between the Bluetooth device and another 
network connection, switching to providing a NAP service, and removing the PANU SDP 
20 record and the GN SDP record; and 

if the local user manually deletes the bridge, removing a NAP SDP record, 
switching back to and readvertising the PANU role, and reinstating the PANU SDP 
record and the GN SDP record. 
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20. A system having a finite state machine for setting and advertising multiple 
Bluetooth PAN profile roles, the system comprising: 

a PANU role state, associated with advertising of both a PANU profile and a GN 
service; 

a GN role state; 

a transition from the PANU role state to the GN role state, associated with a 
connection to the GN service by a remote Bluetooth device; 

a transition from the GN role state to the PANU role state, associated with all 
users of the GN service disconnecting from the GN service; 

a NAP role state; 

a transition to the NAP role state associated with a creation of a bridge to another 
network connection; and 

a transition from the NAP role state to the PANU role state, associated with a 
deletion of the bridge. 

21 . A computer-readable medium having computer-executable instructions 
implementing a method for setting and advertising multiple PAN profile roles in a 
Bluetooth device, the method comprising: 

operating as a PANU while advertising a PANU role and a GN service; 

if a remote device attempts to connect to the GN service, switching to providing 
the GN service, and removing a PANU SDP service record; 

if no remote user of the GN service remains connected, switching back to 
providing the PANU role, readvertising the PANU role, and retaining a GN SDP service 
record; 
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if a local user manually creates a bridge between the Bluetooth device and another 
network connection, switching to providing a NAP service, and removing the PANU SDP 
record and the GN SDP record; and 

if the local user manually deletes the bridge, removing a NAP SDP record, 
5 switching back to and readvertising the PANU role, and reinstating the PANU SDP 
record and the GN SDP record. 
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